home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950528-19950726 / 000321_news@columbia.edu_Tue Jul 11 09:08:36 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA08197
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Wed, 12 Jul 1995 06:16:07 -0400
  3. Received: by apakabar.cc.columbia.edu id AA02704
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 12 Jul 1995 06:16:04 -0400
  5. Path: news.columbia.edu!panix!news.mathworks.com!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: HELP!! kermit not work with TCP/IP ..
  9. Message-Id: <1995Jul11.150836.55845@cc.usu.edu>
  10. Date: 11 Jul 95 15:08:36 MDT
  11. References: <3tu058$hlf@news.cais.com> <1995Jul11.093633.55816@cc.usu.edu> <3tuesm$o4d@news.iastate.edu>
  12. Organization: Utah State University
  13. Lines: 68
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <3tuesm$o4d@news.iastate.edu>, zollner@iastate.edu writes:
  17. > In <1995Jul11.093633.55816@cc.usu.edu>, jrd@cc.usu.edu (Joe Doupnik) writes:
  18. >>    Yes, you don't have the lan adapter handler (ODI, Packet Driver)
  19. >>stuff configured properly. Please review the networking notes distributed
  20. >>with MSK and follow the examples carefully. If you are using ODI then
  21. >>pay very careful attention to syntax because there is no originality
  22. >>permitted in net.cfg.
  23. >>    Joe D.
  24. > 
  25. > Is there an example for how to use a third-party TCP/IP stack (for example 
  26. > from IBM)? The only third-party stack mentioned is from FTP Inc, and that
  27. > needs an extra switch. Is there an (undocumented) switch for the IBM
  28. > TCP/IP stack?
  29. --------------------
  30.     Ok, let's try this again.
  31.     There are, I believe, two (2) IBM TCP/IP stacks: for OS/2 and for
  32. DOS, or in other words protected mode and real mode. Protected mode clients
  33. stand a chance of using the protected mode stack, if built right, but not
  34. the real mode one. And similarly, real mode clients stand a chance of using
  35. the real mode stack, if built right, but not the other one.
  36.     End of part one.
  37.     Begin part two, "if built right."
  38.     These stacks, and similarly for almost all commerical stacks, do
  39. not provide an Int 14h interface or similar by themselves. They have a
  40. proprietary set of calls (and usually an interrupt) which joins them with
  41. matching library modules built into the client application. The library
  42. is also proprietary. The client/lib to/from stack transfer mechanism is
  43. proprietary. The top end of the library usually provides a BSD sockets
  44. interface for the client software. That software must be linked (.obj
  45. modules, Link command) with the library to be a functional executable.
  46.     Now for the discussion and conclusions section, long.
  47.     MS-DOS Kermit cannot be built holding commercial/proprietary
  48. libraries, and it cannot shield vendors from exposing all source code
  49. involved. MS-DOS Kermit is a real mode program, with Windows/DV/OS2
  50. smarts but not dependent on them. It is not a protected mode program,
  51. to restate the obvious. 
  52.     MS-DOS Kermit works well with FTP Inc's DOS TCP/IP offerings, 
  53. because we want it to be so. But that means we go through the FTP TNGLASS
  54. Int 14h module provided by FTP, even though I have their library material
  55. (complements of FTP Inc, with much thanks by the way). MSK works with Novell's
  56. LWP/DOS stack, by design, ditto. And with Beame and Whiteside's TCP/IP 
  57. suite, by design, and ditto. These are all DOS/real mode stacks. Each
  58. involves a vendor provided interface module which is publically documented
  59. and requires no vendor modules within Kermit. B&W has a full function suite
  60. available via an interrupt which MSK uses.
  61.     It's not that we (Kermit) are being picky, but we are dependent on
  62. contributions to make progress with commercial offerings (else out of my 
  63. personal pocket). The above vendors have been most generous with assistance.
  64. We cannot make the Kermit code dependent on anyone's commercial material,
  65. both because folks need to be able to build or redistribute Kermit without
  66. third party copyright/license restrictions and their libraries, and because 
  67. we (Kermit) cannot protect proprietary material from public view in the
  68. distribution products. That means we can't do some nifty things with these 
  69. nice TCP suites, but that's the way it is right now. But we do work with them
  70. in other ways, and their customers are the beneficiaries (which is the whole 
  71. idea).
  72.     MS-DOS Kermit works with other protocol stacks via public interface
  73. mechanisms: DECnet's CTERM and LAT, Novell's NASI/NACS, Meridian Technology's 
  74. SuperLAT, Interconnections TES, variations on NetBIOS, etc. 
  75.     If your (IBM or whatever) TCP/IP stack provides a real mode Int 14h
  76. or similar interface module then MSK should work with it out of the box.
  77. If it does not then sys$error:does_not_work.
  78.     I hope this clarifies the situation a little.
  79.     What do I use with OS/2? Good question. Answer: a second Ethernet
  80. adapter, ODI or Packet Driver (depending on what kind of testing I'm
  81. doing), and MSK in a DOS window. I also use C Kermit for OS/2, and IBM's
  82. own TCP/IP material (stack and applications taken as a whole).
  83.     Joe D.